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Abstract. The focus of this paper is on reducing the complexity in 
verification by exploiting modularity at various levels: in specification, 
in verification, and structurally. For specifications, we use the modular 
language CSP-OZ-DC, which allows us to decouple verification tasks con- 
cerning data from those concerning durations. At the verification level, 
we exploit modularity in theorem proving for rich data structures and use 
this for invariant checking. At the structural level, we analyze possibili- 
ties for modular verification of systems consisting of various components 
which interact. We illustrate these ideas by automatically verifying safety 
properties of a case study from the European Train Control System stan- 
dard, which extends previous examples by comprising a complex track 
topology with lists of track segments and trains with different routes. 

1 Introduction 

Parametric real-time systems arise in a natural way in a wide range of applica- 
tions, including controllers for systems of cars, trains, and planes. Since many 
such systems are safety-critical, there is great interest in methods for ensuring 
that they are safe. In order to verify such systems, one needs (i) suitable formal- 
izations and (ii) efficient verification techniques. In this paper, we analyze both 
aspects. Our main focus throughout the paper will be on reducing complexity 
by exploiting modularity at various levels: in the specification, in verification, 
and also structurally. The main contributions of the paper are: 

(1) We exploit modularity at the specification level. In Sect. 2, we use the modu- 
lar language CSP-OZ-DC (COD), which allows us to separately specify pro- 
cesses (as Communicating Sequential Processes, CSP), data (using Object-Z, 
OZ) and time (using the Duration Calculus, DC). 

(2) We exploit modularity in verification (Sect. 3). 

• First, we consider transition constraint systems (TCSs) that can be auto- 
matically obtained from the COD specification, and address verification 
tasks such as invariant checking. We show that for pointer data struc- 
tures, we can obtain decision procedures for these verification tasks. 
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• Then we analyze situations in which the use of COD specifications allows 
us to decouple verification tasks concerning data (OZ) from verification 
tasks concerning durations (DC). For systems with a parametric number 
of components, this allows us to impose (and verify) conditions on the 
single components which guarantee safety of the overall complex system. 

(3) We also use modularity at a structural level. In Sect. 4, we use results from 
[24] to obtain possibilities for modular verification of systems with complex 
topologies by decomposing them into subsystems with simpler topologies. 

(4) We describe a tool chain which translates a graphical UML version of the 
CSP-OZ-DC specification into TCSs, and automatically verifies the specifi- 
cation using our prover H-PILoT and other existing tools (Sect. 5). 

(5) We illustrate the ideas on a running example taken from the European Train 
Control System standard (a system with a complex topology and a para- 
metric number of components — modeled using pointer data structures and 
parametric constraints), and present a way of fully automatizing verification 
(for given safety invariants) using our tool chain. 

Related work. Model-based development and verification of railway control 
systems with a complex track topology are analyzed in [10]. The systems are 
described in a domain-specific language and translated into SystemC code that 
is verified using bounded model checking. Neither verification of systems with a 
parametric number of components nor pointer structures are examined there. 

In existing work on the verification of parametric systems often only few 
aspects of parametricity are studied together. [21] addresses the verification of 
temporal properties for hybrid systems (in particular also fragments of the ETCS 
as case study) but only supports parametricity in the data domain. [2] presents 
a method for the verification of a parametric number of timed automata with 
real- valued clocks, while in [5] only finite-state processes are considered. In [3], 
regular model checking for a parametric number of homogeneous linear processes 
and systems operating on queues or stacks is presented. There is also work on the 
analysis of safety properties for parametrized systems with an arbitrary number 
of processes operating on unbounded integer variables [1,7,16]. In contrast to 
ours, these methods sacrifice completeness by using either an over-approximation 
of the transition relation or abstractions of the state space. We, on the other 
hand, offer complete methods (based on decision procedures for data structures) 
for problems such as invariant checking and bounded model checking. 

Motivating example. Consider a system of trains on a complex track topology 
as depicted in Fig. 1, and a radio block center (RBC) that has information about 
track segments and trains, like e.g. length, occupying train and allowed maximal 
speed for segments, and current position, segment and speed for trains. We will 
show under which situations safety of the system with complex track topology is 
a consequence of safety of systems with linear track topology. Such modular ver- 
ification possibilities allow us to consider the verification of a simplified version 
of this example, consisting of a linear track (representing a concrete route in the 
track topology) , on which trains are allowed to enter or leave at given points. We 
model a general RBC controller for an area with a linear track topology and an 




Fig. 1. Complex Track Topology Fig. 2. Linear Track Topology 

arbitrary number of trains. For this, we use a theory of pointers with sorts t (for 
trains; next t returns the next train on the track) and s (for segments; with next s , 
prev s describing the next /previous segment on the linear track). The link be- 
tween trains and segments is described by appropriate functions train and segm 
(cf. Fig. 2). In addition, we integrated a simple timed train controller Train into 
the model. This allowed us to certify that certain preconditions for the verifica- 
tion of the RBC are met by every train which satisfies the specification of Train, 
by reasoning on the timed and the untimed part of the system independently. 

2 Modular Specifications: CSP-OZ-DC 

We start by presenting the specification language CSP-OZ-DC (COD) [12,11] 
which allows us to present in a modular way the control flow, data changes, 
and timing aspects of the systems we want to verify. We use Communicating 
Sequential Processes (CSP) to specify the control flow of a system using pro- 
cesses over events; Object-Z (OZ) for describing the state space and its change, 
and the Duration Calculus (DC) for modeling (dense) real-time constraints over 
durations of events. The operational semantics of COD is defined in [11] in terms 
of a timed automata model. For details on CSP-OZ-DC and its semantics, we 
refer to [12,11,9]. Our benefits from using COD are twofold: 

— COD is compositional in the sense that it suffices to prove safety properties 
for the separate components to prove safety of the entire system [11]. This 
makes it possible to use different verification techniques for different parts 
of the specification, e.g. for control structure and timing properties. 

— We benefit from high-level tool support given by Syspect 4 , a UML editor for 
a dedicated UML profile [20] proposed to formally model real-time systems. 
It has a semantics in terms of COD. Thus, Syspect serves as an easy-to-use 
front-end to formal real-time specifications, with a graphical user interface. 

2.1 Example: Systems of Trains on Linear Tracks 

To illustrate the ideas, we present some aspects of the case study mentioned 
in Sect. 1 (the full case study is presented in [8]). We exploit the benefits of 
COD in (i) the specification of a complex RBC controller; (ii) the specification 
of a controller for individual trains; and (iii) composing such specifications. Even 
though space does not allow us to present all details, we present aspects of the 
example which cannot be considered with other formalisms, and show how to 
cope in a natural way with parametricity. 



4 http: //csd. inf ormatik.uni- oldenburg. de/~ syspect/ 
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CSP part. The processes and their interdependency is specified using the CSP 
specification language. The RBC system passes repeatedly through four phases, 
modeled by events with corresponding COD schemata updSpd {speed update), 
req (request update), alloc (allocation update), and updPos (position update). 

CSP: 

method enter : [si? : Segment; £0? : Train; fl? : Train; t2? : Train] 
method leave : [Is? : Segment; It? : Train] 
local_chan alloc, req, updPos, updSpd 



n.a.in=((updSpd^ Statel) Statel=((req^State2) State2=((alloc—>State3) State3=((updPos^m3Lin) 

□ (/eaue^main) U[leave— >Statel) U{leave^rState2) □ {leaver StateZ) 

□ (erater-Mnain)) a(enter^Statel)) 0(enter^State2)) U(enter^State3)) 



The speed update models the fact that every train chooses its speed according 
to its knowledge about itself and its track segment as well as the next track 
segment. The request update models how trains send a request for permission 
to enter the next segment when they come close to the end of their current 
segment. The allocation update models how the RBC may either grant these 
requests by allocating track segments to trains that have made a request, or 
allocate segments to trains that are not currently on the route and want to 
enter. The position update models how all trains report their current positions 
to the RBC, which in turn de-allocates segments that have been left and gives 
movement authorities to the trains. Between any of these four updates, we can 
have trains leaving or entering the track at specific segments using the events 
leave and enter. The effects of these updates are defined in the OZ part. 



OZ part. The OZ part of the specification consists of data classes, axioms, the 
Init schema, and update rules. 

Data classes. The data classes declare function symbols that can change their 
values during runs of the system, and are used in the OZ part of the specification. 



. SegmentData 

train : Segment Train 
req : Segment — ► Z 
alloc : Segment — > Z 



[Train on segment] 
[Requested by train] 
[Allocated by train] 



_ TrainData 

segm : Train — > Segment 
next : Train — > Train 
spd : Train -> M 
pos : Train — > R 
prev : Train — > Train 



[Train segment] 
[Next train] 
[Speed] 
[Current position] 
[Prev. train] 



Axioms. The axiomatic part defines properties of the data structures and 
system parameters which do not change during an execution of the system: 
gmax : R (the global maximum speed), decmax : R (the maximum deceleration 
of trains), d : M. (a safety distance between trains), and bd : R — > R (mapping 
the speed of a train to a safe approximation of the corresponding braking dis- 
tance). We specify properties of those parameters, among which an important 
one is d > bd(gmax) + gmax ■ At stating that the safety distance d to the end 
of the segment is greater than the braking distance of a train at maximal speed 
gmax plus a further safety margin (distance for driving At time units at speed 
gmax). Furthermore, unique, non-negative ids for trains (sort Train) and track 
segments (sort Segment) are defined. The route is modeled as a doubly-linked 
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list 5 of track segments, where every segment has additional properties specified 
by the constraints in the state schema, \/ t: Train . ud(t) > o 

E.g., sid is increasing along the 
nexts pointer, the length of a seg- 
ment is bounded from below in terms 
of d and gmax -At, and the differ- 
ence between local maximal speeds on 
neighboring segments is bounded by 
decmax ■ At. Finally, we have a func- 
tion incoming, the value of which is 
cither a train which wants to enter the given segment from outside the current 
route, or tnil if there is no such train. Although the valuation of incoming can 
change during an execution, we consider the constraint (*) as a property of our 
environment that always holds. Apart from that, incoming may change arbi- 
trarily and is not explicitly updated. Note that Train and Segment are pointer 
sorts with a special null element (tnil and snil, respectively), and all constraints 
implicitly only hold for non-null elements. So, constraint (*) actually means 
V si, s2 : Segment \ si =fc snil s2 A mcoming(sl) =fc tnil A train(s2) ^ tnil 
• tid(incoming(sl)) ^ tid(tratn(s2)) 

Init schema. The I nit schema de- 
scribes the initial state of the system. 
It essentially states that trains are ar- 
ranged in a doubly-linked list, that all 
trains are initially placed correctly on 
the track segments and that all trains 
respect their speed limits. 

Update rules. Updates of the state space, that are executed when the cor- 
responding event from the CSP part is performed, are specified with effect 
schemata. The schema for updSpd, for instance, consists of three rules, distin- 
guishing (i) trains whose distance to the end of the segment is greater than the 
safety distance d (the first two lines of the constraint), (ii) trains that are beyond 
the safety distance near the end of the segment, and for which the next segment 
is allocated, and (iii) trains that are near the end of the segment without an al- 
location. In case (i) , the train can choose an arbitrary speed below the maximal 
speed of the current segment. In case (ii), the train needs to brake if the speed 
limit of the next segment is below the current limit. In case (iii), the train needs 
to brake such that it safely stops before reaching the end of the segment. 

. effect_updSpd 

A(spd) 

V£ : Train \ pos(t) < length(segm(t)) — d A spd(t) — decmax ■ At > 

• rnax{Q, spd(t) — decmax • At} < spd' (t) < lmax(segm(t)) 

V£ : Train | pos(t) > length(segm(t)) — d A alloc{nexts{segm{t))) — tid(t) 

• max{0, spd(t) — decmax • At} < spd' (t) < min{lmax(segm(t)) , lmax(nexts(segm(t)))} 
V£ : Train | pos(t) > length(segm(t)) — d A -i alloc(nexts(segm(t))) — tid(t) 

• spd (t) — max{0, spd(t) — decmax • At} 



5 Note that we use relatively loose axiomatizations of the list structures for both trains 
and segments, also allowing for disjoint families of linear, possibly infinite lists. 



VII, t2 : Train (1 =1 tl • tid(tl) / tid(t2) 

Vs : Segment • prevs (nexts (s)) — s 

Vs : Segment • nexts(prevs(s)) — s 

Vs : Segm,ent • sid(s) > 

Vs : Segment • sid(nexts(s)) > sid(s) 

Vsl, ,s2 : Segment | si / ,s2 • sid(sl) / sid(s2) 

Vs : Segment \ s ^ snil • length(s) > d + gmax • At 

Vs : Segment | s ^ snil • < lmax(s) A lmax(s) < gmax 

Vs : Segment • lmax(s) > lmax(prevs(s)) — decmax ■ At 

Vsl,s2 : Segment • tid(incoming(sl)) ^ tid(train(s2)) (*) 



Init 

yt : Train • train(segm(t)) — t 

V t : Train • next(prev(t)) — t 

: Train • prev(next(t)) — t 
yt : Train • < pos(t) < length(segm(t)) 

V t : Train • < spd(t) < lmax(segm(t)) 
yt : Train • alloe(segm(t)) — tid(t) 

V t : Train • alloc(nexts(segm(t))) — tid(t) 

V length(segm(t)) - bd(spd(t)) > pos(t) 
Vs : Segment • segm,(train(s)) — s 
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Timed train controller. 

In the DC part of a speci- 
fication, real-time constraints 
are specified: A second, timed 
controller Train (for one train 
only) interacts with the RBC Fig. 3. Structural overview 

controller, which is presented in the overview of the case study in Fig. 3. The 
train controller Train consists of three timed components running in parallel. The 
first updates the train's position. This component contains e.g. the DC formula 

^{true ^XupdPos ~ (t < At) ~ $ updPos ~ true), 

that specifies a lower time bound At on updPos events. The second component 
checks periodically whether the train is beyond the safety distance to the end 
of the segment. Then, it starts braking within a short reaction time. The third 
component requests an extension of the movement authority from the RBC, 
which may be granted or rejected. The full train controller can be found in [8]. 



3 Modular Verification 



In this section, we combine two approaches for the verification of safety properties 
of COD specifications: 

— We introduce the invariant checking approach and present decidability re- 
sults for local theory extensions that imply decidability of the invariant 
checking problem for a large class of parameterized systems. 

- We illustrate how we can combine this invariant checking for the RBC speci- 
fication with a method for model checking of real-time properties (introduced 
in [19]) for the COD specification for a single train Train. 

Formally, our approach works on a transition constraint system (TCS) obtained 
from the COD specification by an automatic translation (see [9]) which is guar- 
anteed to capture the defined semantics of COD (as defined in [11]). 

Definition 1. The tuple T = (V,E, (Init), (Update)) is a transition constraint 
system, which specifies: the variables (V ) and function symbols (E) whose values 
may change over time; a formula (Init) specifying the properties of initial states; 
and a formula (Update) which specifies the transition relation in terms of the 
values of variables x e V and function symbols f E E before a transition and 
their values (denoted x' , f) after the transition. 

In addition to the TCS, we obtain a background theory T from the specification, 
describing properties of the used data structures and system parameters that do 
not change over time. Typically, T consists of a family of standard theories (like 
the theory of real numbers), axiomatizations for data structures, and constraints 
on system parameters. In what follows (f>\=i-tj) denotes logical entailment and 
means that every model of the theory T which is a model of <j) is also a model 
for tp. We denote false by _L, so </>|=t^- means that <f> is unsatisfiable w.r.t. T ■ 
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3.1 Verification Problems 

We consider the problem of invariant checking of safety properties. 6 To show 
that a safety property, represented as a formula (Safe), is an invariant of a TCS 
T (for a given background theory T), we need to identify an inductive invariant 
(Inv) which strengthens (Safe), i.e., we need to prove that 

(1) (Inv) hr (Safe), 

(2) (Init) hr (Inv), and 

(3) (Inv) A (Update) \=j- (Inv'), where (Inv') results from (Inv) by replacing each 
x G V by x' and each / <G S by /'. 

Lemma 2. If (Inv), (Init) and (Update) belong to a class of formulae for which 
the entailment problems w.r.t. T above are decidable then the problem of checking 
that (Inv) is an invariant of T (resp. T satisfies the property (Safe) ) is decidable. 

We use this result in a verihcation-design loop as follows: We start from a spec- 
ification written in COD. We use a translation to TCS and check whether a 
certain formula (Inv) (usually a safety property) is an inductive invariant. 

(i) If invariance can be proved, safety of the system is guaranteed. 

(ii) If invariance cannot be proved, we have the following possibilities: 

1. Use a specialized prover to construct a counterexample (model in which the 
property (Inv) is not an invariant) which can be used to find errors in the 
specification and/or to strengthen the invariant 7 . 

2. Using results in [25] we can often derive additional (weakest) constraints on 
the parameters which guarantee that Inv is an invariant. 

Of course, the decidability results for the theories used in the description of a 
system can be also used for checking consistency of the specification. 

If a TCS models a system with a parametric number of components, the for- 
mulae in problems (l)-(3) may contain universal quantifiers (to describe proper- 
ties of all components) , hence standard SMT methods - which are only complete 
for ground formulae - do not yield decision procedures. In particular, for (ii) (1,2) 
and for consistency checks we need possibilities of reliably detecting satisfiability 
of sets of universally quantified formulae for which standard SMT solvers cannot 
be used. We now present situations in which this is possible. 

3.2 Modularity in Automated Reasoning: Decision Procedures 

We identify classes of theories for which invariant checking (and bounded model 
checking) is decidable. Let To be a theory with signature 77 = (So, So, Pred), 
where So is a set of sorts, and S and Pred are sets of function resp. predicate 
symbols. We consider extensions of % with new function symbols in a set S, 
whose properties are axiomatized by a set /C of clauses. 



6 We can address bounded model checking problems in a similar way, cf. [15,9,13]. 

7 This last step is the only part which is not fully automatized. For future work we 
plan to investigate possibilities of automated invariant generation or strengthening. 
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Local theory extensions. We are interested in theory extensions in which for 
every set G of ground clauses we can effectively determine a finite (preferably 
small) set of instances of the axioms K, sufficient for checking satisfiability of 
G without loss of completeness. If G is a set of 7T c -clauses (where 27 c is the 
extension of 77 with constants in a set E c ), we denote by st(/C, G) the set of 
ground terms starting with a S- function symbol occurring in K, or G, and by 
K\G] the set of instances of /C in which the terms starting with ^-functions are 
in st(/C, G). 7oU/C is a local extension of 7o [23] if the following condition holds: 

(Loc) For every set G of ground clauses, G ^r Q vK^- iff /C[G] U G \=j-s± 

where T E is the extension of % with the free functions in E. We can define 
stable locality (SLoc) in which we use the set K\ G ^ of instances of /C in which 
the variables below Z 1 - functions are instantiated with terms in st(/C, G). In local 
theory extensions, sound and complete hierarchical reasoning is possible. 

Theorem 3 ([23]). With the notations introduced above, ifT^Q 7oU/C satisfies 
condition ((S)Loc) then the following are equivalent to G \=r ulC^- : 

(1) /C*[G]UG hr s ^ (fC*[G] is KL[G] for local; /C [G1 for stably local extensions). 

(2) /CoUGoU-D \=q-sL, where /CoUGo U D is obtained from /C*[G]UG by intro- 
ducing (bottom-up) new constants Ct for subterms t = f(g\,...,g n ) with 
f e S, gi ground E U S c -terms; replacing the terms with the corresponding 
constants; and adding the definitions Ct ~ t to the set D . 

(3) /C UG U7V \=%^, wh ere 

n 

N = {/\ Ci« d % ^ c = d\ /(ci, . . . , c„) « c,f(d 1 ,. . . , d n ) w d G D}. 

i=i 

The hierarchical reduction method is implemented in the system H-PILoT [14] . 

Corollary 4 ([23]). If the theory extension % C 71 satisfies ((S)Loc) then sat- 
isfiability of sets of ground clauses G w.r.t. 71 is decidable if IC*[G] is finite and 
/CoUGoUiVo belongs to a decidable fragment J 7 of To- Since the size o//CoUGoU7Vo 
is polynomial in the size of G (for a given JC), locality allows us to express the 
complexity of the ground satisfiability problem w.r.t. 71 as a function of the com- 
plexity of the satisfiability of T '-formulae w.r.t. %■ 

3.3 Examples of Local Theory Extensions 

We are interested in reasoning efficiently about data structures and about up- 
dates of data structures. We here give examples of such theories. 

Update axioms. In [13] we show that update rules Update^, E') which de- 
scribe how the values of the ^-functions change, depending on a set {<f>i \ i € 1} 
of mutually exclusive conditions, define local theory extensions. 

Theorem 5 ([13]). Assume that {4>i i £ 1} are formulae over the base signa- 
ture such that (j>i(x) A 4>j(x) \=j- _L for i^j , and that Sj, U are (possibly equal) 
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terms over the signature E such that % \= V ' x(^>i(x)—>Si(x)<ti(x)) for all i G I. 
Then the extension of To with axioms of the form Def(/) is local. 

Def(/) Vx(Mx) -> < f(x) < U{x))i G /. 

Data structures. Numerous locality results for data structures exist, e.g. for 
fragments of the theories of arrays [6,13], and pointers [18,13]. As an illustration 
- since the model we used in the running example involves a theory of linked 
data structures - we now present a slight extension of the fragment of the theory 
of pointers studied in [18,13], which is useful for modeling the track topologies 
and successions of trains on these tracks. We consider a set of pointer sorts 
P = {pi, . . . , p n } and a scalar sort s. 8 Let (E s , Pred s ) be a scalar signature, and 
let Ep be a set of function symbols with arguments of pointer sort consisting 
of sets Sp^ s (the family of functions of arity p— >s), and Ep^ p (the family of 
functions of arity p— >Pi). (Here p is a tuple p, 1 . . . Pi k with k > 0.) We assume 
that for every pointer sort p G P, Ep contains a constant null p of sort p. 

Example 6. The fact that we also allow scalar fields with more than one argu- 
ment is very useful because it allows, for instance, to model certain relationships 
between different nodes. Examples of such scalar fields could be: 

- distance^, q) associates with non-null p, q of pointer type a real number; 

— reachable(p, q) associates with non-null p, q of pointer type a boolean value 
(true (1) if q is reachable from p using the next functions, false (0) otherwise). 

Let E = EpU E s . In addition to allowing several pointer types and functions of 
arbitrary arity, we loosen some of the restrictions imposed in [18,13]. 

Definition 7. An extended pointer clause is a formula of formV p. (£Vtp)(p), 
where p is a set of pointer variables including all free variables of £ and p, and: 

(1) £ consists of disjunctions of pointer equalities, and has the property that for 
every term t = f(h, . . . ,tk) with f G Ep occurring in £ V ip, £ contains an 
atom of the form t' = null p for every proper subterm (of sort p) t' of t; 

(2) ip is an arbitrary formula of sort s. 

£ and (p may additionally contain free scalar and pointer constants, and ip may 
contain additional quantified variables of sort s. 

Theorem 8. Let E = Ep U E s be a signature as defined before. Let T s be a 
theory of scalars with signature E s . Let([> be a set of E- extended pointer clauses. 
Then, for every set G of ground clauses over an extension E c of E with constants 
in a countable set c the following are equivalent: 

(1) G is unsatisfiable w.r.t. & {_)%; 

(2) ^ G 'UG is an unsatisfiable set of clauses in the disjoint combination T s U£Qp 
ofTs and £Qp, the many-sorted theory of pure equality over pointer sorts, 



We assume that we only have one scalar sort for simplicity of presentation; the scalar 
theory can itself be an extension or combination of theories. 
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where consists of all instances of<P in which the universally quantified vari- 
ables of pointer type occurring in <P are replaced by ground terms of pointer type 
in the set st(<£, G) of all ground terms of sort p occurring in $ or in G. 

The proof is similar to that in [13]. H-PILoT can be used as a decision procedure 
for this theory of pointers - if the theory of scalars is decidable - and for any 
extension of this theory with function updates in the fragment in Thm. 5. 

Example 9. Let P = {sg(segment), t(train)}, and let next t ,prev t : t — > t, and 
next s , prev s : sg — > sg, and train : sg — >• t, segm : t — >• sg, and functions of scalar 
sort as listed at the beginning of Sect. 2.1. All axioms describing the background 
theory and the initial state in Sect. 2.1 are expressed by extended pointer clauses. 
The following formula expressing a property of reachability of trains can be 
expressed as a pointer clause: 

Vp, q(p 7^ null t Ag ^ null t Anext t (q) ^ null; — ► (reachable(p, q) — > reachable(p, nextt(q))). 

Decidability for verification. A direct consequence of Thm. 3 and Cor. 4 is 
the following decidability result for invariant checking: 

Corollary 10 ([25]). Let T be the transition constraint system and T be the 
background theory associated with a specification. If the update rules Update and 
the invariant property Inv can be expressed as sets of clauses which define a chain 
of local theory extensions T C TU lnv(a?,/) C TU lnv(af,/) U Update(x, a;',/,/ ) 
then checking whether a formula is an invariant is decidable. 

In this case we can use H-PILoT as a decision procedure (and also to construct 
a model in which the property Inv is not an invariant). We can also use results 
from [25] to derive additional (weakest) constraints on the parameters which 
guarantee that Inv is an invariant. 

3.4 Example: Verification of the Case Study 

We demonstrate how the example from Sect. 1 can be verified by using a com- 
bination of the invariant checking approach presented in Sect. 3.1 and a model 
checking approach for timing properties. This combination is necessary because 
the example contains both the RBC component with its discrete updates, and 
the train controller Train with real-time safety properties. Among other things, 
the specification of the RBC assumes that the train controllers always react in 
time to make the train brake before reaching a critical position. 

Using the modularity of COD, we can separately use the invariant checking 
approach to verify the RBC for a parametric number of trains, and the approach 
for model checking DC formulae to verify that every train satisfies the timing 
assumptions made in the RBC specification. 

Verification of the RBC. The verification problems for the RBC are satis- 
fiability problems containing universally quantified formulae, hence cannot be 
decided by standard methods of reasoning in combinations of theories. Instead, 
we use the hierarchical reasoning approach from Sect. 3.2. 
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Safety properties. As safety property for the RBC we want to prove that we 
never have two trains on the same segment: 

(Safe) := Vfi, t 2 : Train. t\ ^ ti — \ id s {segm{t\)) ^ id s (segm(t2)) ■ 

To this end, we need to find a formula (Inv) such that we can prove 

(1) (Inv) U -.(Safe) \= T -L, 

(2) (Init) U -.(Inv) \= T -L, and 

(3) (Inv) U (Update) U -.(Inv') |= r -L, 

where (Update) is the update formula associated with the transition relation 
obtained by translating the COD specification into TCS [11,9], and (Init) consists 
of the constraints in the Init schema. The background theory T is obtained 
from the state schema of the OZ part of the specification: it is the combination 
of the theories of real numbers and integers, together with function and constant 
symbols satisfying the constraints given in the state schema. 

Calling H-PILoT on problem (3) with (Inv) = (Safe) shows us that (Safe) 
is not inductive over all transitions. Since we expect the updates to preserve 
the well-formedness properties in (Init), we tried to use this as our invariant, 
but with the same result. However, inspection of counterexamples provided by 
H-PILoT allowed us to identify the following additional constraints needed to 
make the invariant inductive: 

(Indi) := Wt : Train, pc 7^ ImtState A alloc(nexts(segm(t))) 7^ tid(t) 

— > length(segm(t)) — bd(spd(t)) > pos(t) + spd(t) ■ At 

(Ind2) :=Vt: Train, pc =fc InitState A pos(t) > length(segm(t)) — d 
— y spd(t) < lmax(nexts(segm(t))) 

The program counter pc is introduced in the translation process from COD to 
TCS and we use the constraint pc 7^ InitState to indicate that the system is 
not in its initial location. Thus, define (Inv) as the conjunction (Init) A (Indi) A 
(Ind2). Now, all of the verification tasks above can automatically be proved us- 
ing Syspect and H-PILoT, in case (3) after splitting the problem into a number 
of sub-problems. To ensure that our system is not trivially safe because of in- 
consistent assumptions, we also check for consistency of T, (Inv) and (Update). 
Since by Thm. 5 all the update rules in the RBC specification define local theory 
extensions, and the axioms specifying properties of the data types are extended 
pointer clauses, by Cor. 10 we obtain the following decidability result. 

Corollary 11. Checking properties (l)-(3) is decidable for all formulae Inv ex- 
pressed as sets of extended pointer clauses with the property that the scalar part 
belongs to a decidable fragment of the theory of scalars. 

Topological invariants. We also considered certain topological invariants of the 
system - e.g. that if a train t is inserted between trains t\ and fe, the next and 
prev links are adjusted properly, and if a train leaves a track then its nextt and 
prev 4 links become null. We also checked that if certain reachability conditions - 
modeled using a binary transitive function reachable with Boolean output which 
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is updated when trains enter or leave the line track - are satisfied before an 
insertion/removal of trains then they are satisfied also after. We cannot include 
these examples in detail here; they will be presented in a separate paper. 

Verification of the timed train controller. Using the model checking ap- 
proach from [19], we can automatically prove real-time properties of COD spec- 
ifications. In this case, we use the approach only on the train controller part 
Train (Fig. 3). We show that the safety distance d and the braking distance bd 
postulated in the RBC controller model can actually be achieved by trains that 
comply with the train specification. That is, we prove that (for an arbitrary 
train) the train position curPos is never beyond its movement authority ma: 

(Safej) := ->0{curPos > ma). 

Safety of the overall system. The safety property for trains (Safej) im- 
plies that train controllers satisfying the specification also satisfy the timing 
assumptions made implicitly in the RBC controller. Compositionality of COD 
guarantees [11] that it is sufficient to verify these components separately. Thus, 
by additionally proving that (Inv) is a safety invariant of the RBC, we have 
shown that the system consisting of a combination of the RBC controller and 
arbitrarily many train controllers is safe. 



4 Modular Verification for Complex Track Topologies 

We now consider a complex track as described in Fig. 1. Assume that the track 
can be modeled as a directed graph G = ( V, E) with the following properties: 

(i) The graph G is acyclic (the rail track does not contain cycles); 

(ii) The in-degree of every node is at most 2 (at every point at which two lines 
meet, at most two linear tracks are merged). 

Theorem 12. For every track topology satisfying conditions (i) and (ii) above 
we can find a decomposition C = {ltrack 2 | i G 1} into linear tracks such that 
if (x,y) G E then y = next^ r3ck ' (x) for some i G I and for every Itrack G C 
identifiers are increasing w.r.t. next^ track . 

We assume that for each linear track Itrack we have one controller i?5C ltrack 
which uses the control protocol described in Sect. 2.1, where we label the func- 
tions describing the train and segment succession using indices (e.g. we use 
next' t track , prevj track for the successor /predecessor of a train on Itrack, and next[, track , 
p rev itrack f Qr successor/predecessor of a segment on Itrack. Assume that 
these controllers are compatible on their common parts, i.e. (1) if two tracks 
tracki, track2 have a common subtrack tracks then the corresponding fields agree, 
i.e. whenever s, next* racki (s) are on track 3 , next t s rackl (s)=next* rack2 (.s)=next t / ack3 (s) 
(the same for prev s , and for next t , prev t on the corresponding tracks); (2) the up- 
date rules are compatible for trains jointly controlled. 9 Under these conditions, 



We also assume that all priorities of the trains on the complex track are different. 
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Fig. 4. Tool chain 



proving safety for the complex track can be reduced to checking safety of linear 
train tracks with incoming and outgoing trains (for details cf. [8]). 

Lemma 13. A state s of the system is a model (F t , P S ,R, Z, {next ltrack , prev ltrack , 
next^ track , preVj track }t r acke£ U {segm, train, pos, ...}), where all the functions rela- 
tivized to tracks are compatible on common subtracks. The following hold: 

(a) Every state s of the system of trains on the complex track restricts to a state 
sitrack of the system of trains on its component linear track. 

(b) Any family {sitrack, i 6 1} of states on the component tracks which agree on 
the common sub-tracks can be "glued together" to a state s of the system of 
trains on the complex track topology. 

(a) and (b) also hold if we consider initial states (i.e. states satisfying the initial 
conditions) and safe states (i.e. states satisfying the safety conditions in the 
invariant InvJ. Similar properties hold for parallel actions and for transitions. 

Theorem 14. Consider a complex track topology satisfying conditions (i)-(ii) 
above. Let C = {ltrack 2 | i e 1} be its decomposition into a finite family of finite 
linear tracks such that for all Itracki, Itrack2 G C, C contains all their common 
maximal linear subtracks. Assume that the tracks Itracki 6 C (with increasing 
segment identifiers w.r.t. next^ track J are controlled by controllers RBC hrackl using 
the protocols in Sect. 2.1 which synchronize on common subtracks. Then we can 
guarantee safety of the control protocol for the controller of the complex track 
obtained by interconnecting all linear track controllers {RBC hrack ' | i 6 I}. 

5 Prom Specification to Verification 

For the practical application of verification techniques tool support is essential. 
For this reason, in this section we introduce a full tool chain for automatically 
checking the invariance of safety properties starting from a given specification 
and give some experimental results for our RBC case study. 

Tool chain. The tool chain is sketched in Fig. 4. In order to capture the systems 
we want to verify, we use the COD front-end Syspect (cf. Sect. 2). [11] defines 
the semantics of COD in terms of a timed automata model called Phase Event 
Automata (PEA). A translation from PEA into TCS is given in [11], which is 
implemented in the PEA toolkit 10 and used by Syspect. 

Given an invariance property, a Syspect model can directly be exported into a 
TCS in the syntax of H-PILoT. If the specification's background theory consists 
of chains of local theory extensions, the user needs to specify via input dialog 



http://csd. informatik.uni-oldenburg.de/projects/epea.html 
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(i) that the pointer extension of H-PILoT is to be used; (ii) which level of exten- 
sion is used for each function symbol of the specification. With this information, 
our tool chain can verify invariance of a safety condition fully automatically 
by checking its invariance for each transition update (cf. Sect. 3.1). Therefore, 
for each update, Syspect exports a file that is handed over to H-PILoT. The 
safety invariance is proven if H-PILoT detects the unsatisfiability of each verifi- 
cation task. Otherwise, H-PILoT generates a model violating the invariance of 
the desired property, which may be used to fix the problems in the specification. 

In addition, the PEA toolkit also supports output of TCS into the input 
language of the abstraction refinement model checker ARMC [22], which we 
used to verify correctness of the timed train controller from our example. 

Experimental results. Table 1 gives experimental 
results for checking the RBC controller. 11 The ta- 
ble lists execution times for the involved tools: (sys) 
contains the times needed by Syspect and the PEA 
toolkit to write the TCS, (hpi) the time of H-PILoT 





(sys) (hpi) 


(y ic ) 


(Inv) unsat 






Part 1 


lis 72s 


52s 


Part 2 


lis 124s 


131s 


speed update 


lis 8s 


45s 


(Safe) sat 


9s 8s 


t.o. 


Consistency 


13s 3s 


(U) 2s 



to compute the reduction and to check satisfiabil- (obtained on: AMD64, dual-core 
ity with Yices as back-end, (yic) the time of Yices TablVl^sults 
to check the proof tasks without reductions by H- 

PILoT. Due to some semantics-preserving transformations during the translation 
process the resulting TCS consists of 46 transitions. Since our invariant (Inv) is 
too complex to be handled by the clausifier of H-PILoT, we check the invariant 
for every transition in two parts yielding 92 proof obligations. In addition, results 
for the most extensive proof obligation are stated: one part of the speed update. 
Further, we performed tests to ensure that the specifications are consistent. 

The table shows that the time to compute the TCS is insignificant and that 
the overall time to verify all transition updates with Yices and H-PILoT does 
not differ much. On the speed update H-PILoT was 5 times faster than Yices 
alone. During the development of the case study H-PILoT helped us finding 
the correct transition invariants by providing models for satisfiable transitions. 
The table lists our tests with the verification of condition (Safe), which is not 
inductive over all transitions (cf. Sect. 3): here, H-PILoT was able to provide a 
model after 8s whereas Yices detected unsatisfiability for 17 problems, returned 
"unknown" for 28, and timed out once (listed as (t.o) in the table). For the 
consistency check H-PILoT was able to provide a model after 3s, whereas Yices 
answered "unknown" (listed as (U)). 

In addition, we used ARMC to verify the property (Safej) of the timed train 
controller. The full TCS for this proof tasks comprises 8 parallel components, 
more than 3300 transitions, and 28 real-valued variables and clocks (so it is 
an infinite state system). For this reason, the verification took 26 hours (on a 
standard desktop computer). 



11 Note that even though our proof methods fully support parametric specifications, 
we instantiated some of the parameters for the experiments because the underlying 
provers Yices and ARMC do not support non-linear constraints. 
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6 Conclusion 

We augmented existing techniques for the verification of real-time systems to 
cope with rich data structures like pointer structures. We identified a decidable 
fragment of the theory of pointers, and used it to model systems of trains on 
linear tracks with incoming and outgoing trains. We then proved that certain 
types of complex track systems can be decomposed into linear tracks, and that 
proving safety of train controllers for such complex systems can be reduced to 
proving safety of controllers for linear tracks. We implemented our approach in 
a new tool chain taking high-level specifications in terms of COD as input. To 
uniformly specify processes, data and time, [17,4,26] use similar combined spec- 
ification formalisms. We preferred COD due to its strict separation of control, 
data, and time, and its compositionality (cf. Sect. 2), which is essential for auto- 
matic verification. There is also sophisticated tool support given by Syspect and 
the PEA toolkit. Using this tool chain we automatically verified safety properties 
of a complex case study, closing the gap between a formal high-level language 
and the proposed verification method for TCS. We plan to extend the case study 
to also consider emergency messages (like in [9]), possibly coupled with updates 
in the track topology, or updates of priorities. Concerning the track topology, 
we are experimenting with more complex axiomatizations (e.g. for connected- 
ness properties) that are not in the pointer fragment presented in Sect. 3.3; we 
already proved various locality results. We also plan to study possibilities of 
automated invariant generation in such parametric systems. 

Acknowledgments. Many thanks to Werner Damm, Ernst-Rudiger Olderog 
and the anonymous referees for their helpful comments. 
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